今天天來淺聊建立共同使用的文字通訊平台的經驗，並針對「三探敏捷」的故事做個總結。

導入 Slack 的經驗

在過去，實驗室都是使用 LINE 溝通，至少在教授與學生之間是。雖然另外有一個畢業學長姐建立的 Telegram 群組，但那是以聊天為主，而不是工作用的。

承襲在實習的經驗，我想嘗試讓實驗室擁有一個 Slack Channel，除了可以有一個比較正式的溝通平台外、並且依照主題進行內部溝通，也可以將一些通知訊息導在上面。我們的專案也就有專門的頻道可以進行討論。溝通方式也從原本的只有面對面溝通，多了能夠透過文字非同步溝通的管道。

儘管在現在聽起來是非常稀鬆平常的是，但在 2016 年時，Slack 以及這類工作用並能夠過 Webhook 與大量服務整合的即時通訊平台還沒起來，而 IRC 這類傳統通訊方式也已落寞，算是落在一個空窗期，即時通訊仍是以聊天為主的應用程式為主流。

有了 Slack 之後，我們就可以透過 Slack 整合 GitLab 的通知，知道程式碼有誰做出了變動、有沒有誰提出 MR 需要幫忙 Code Review 的。有資訊要傳達或是有問題也可以在頻道上 mention 某人，並在有空時進行討論。這對於各有課表的學生來說是滿重要的改變，畢竟若是見面時間重疊不多，仍執意使用面對面溝通，就會產生許多等待的浪費，更可能有因為資訊過時導致的錯誤發生。

這次的經驗讓我暸解到非同步溝通方式的重要，而文字訊息在訊息輸出的速率雖然比言語慢，但是啟動的成本卻是低的，我不用等待一個時間再去開啟對話，而是隨時有想法就可以發送。降低了訊息的發送門檻，也讓透明度有所提升。

另外整合服務的通知到 Slack 也可以縮短我們從事情發生到發現事情發生的時間，讓我可以更快的去反應。

總結

原本以為三探敏捷可以一篇解決的我，果然太天真了。 XDDDDD
這三天聊了碩士時期進行的一些嘗試，有成功、也有失敗，而這些經驗對當時的我或許是鼓舞、或許是帶來更多困惑，這些都是前進的動力。對現在的我則更多是經過反思更去暸解當時成功會失敗的原因。

敏捷是要能快速反應；為了能夠快速反應，我們要有能夠因應變化的適應力；而適應力則相依著透明度，無論是現況的透明、還是知識的透明。

所以這些過往的經驗給了我一些收穫：

1. 自動化降低時間成本，讓團隊能夠有更多精力放在重要的事，以提高適應力
2. Code Review 增加知識傳承與激發互動、討論
3. Daily Scrum 重點在製造互動機會，而不是為了開而開
4. 當同步溝通遇上困難時，可以嘗試非同步溝通。但要記住兩者各有適合的使用情境。
5. 為導入而導入通常以失敗告終，重點在知道要解決什麼問題。這樣才不會只是追求形式，也才能說服夥伴一起執行。